home *** CD-ROM | disk | FTP | other *** search
/ Experimental BBS Explossion 3 / Experimental BBS Explossion III.iso / gus / digestv3.zip / V3N5M.TXT < prev    next >
Text File  |  1993-12-05  |  11KB  |  261 lines
  1. Apparently-To: john.smith@gravis.com
  2.  
  3.  
  4. GUS Musician's Digest       Sun, 5 Dec 93  2:27          Volume 3: Issue   5  
  5.  
  6. Today's Topics:
  7.                      GUS Musician's Digest V3 #4
  8.                              MIDI circuit
  9.                             Patch Banking
  10.                    Patch banking and custom patches
  11.  
  12. Standard Info:
  13.     - Meta-info about the GUS can be found at the end of the Digest.
  14.     - Before you ask a question, please READ THE FAQ.
  15.  
  16. ----------------------------------------------------------------------
  17.  
  18. Date: Sat, 4 Dec 1993 16:24:40 -0600 (CST)
  19. From: Antonio Guia <guia@CC.UManitoba.CA>
  20. Subject: Re: GUS Musician's Digest V3 #4
  21.  
  22. to whomever posted the pin mapping for the optocoupler chips:
  23.  
  24. one more comment to add that you forgot about, the notch on the end of the
  25. chip is usually a square cut or half-circle cut on the TOP end of the
  26. chip, or a little dot on the TOP RIGHT corner of the chip, so that the
  27. chip's pins are number from number 1 on the top left, increasing downward
  28. on the left, then across to the other side and increasing upward on the
  29. right so that the highest pin number is beside that dot, or on the top
  30. right corner of the chip.
  31.  
  32. also worthy of noting is that usually the vcc (positive voltage) is fed to
  33. pin 1 to supply power to the chip, and the ground for the chip is the last
  34. pin on the top right (pin 8 in an 8-pin chip, or pin 32 in a 32-pin chip, etc)
  35.  
  36. your map along with which side is the top of the chip should probably be
  37. included in the FAQ though.
  38.  
  39. ------------------------------
  40.  
  41. Date: Sat, 4 Dec 93 22:09:34 EST
  42. From: dulimart@cps.msu.edu (Hansye S. Dulimarta)
  43. Subject: MIDI circuit
  44.  
  45.    Date: Thu, 02 Dec 1993 22:17:15 +0200
  46.    From: PWRJAM01@Uctvax.UCT.AC.ZA
  47.  
  48.    Thanks to all of you who replied my questions about the midi circuit -
  49.    there were quite a few replies...  I am in the middle of a tough battle
  50.    with this damn circuit!
  51.  
  52.    1]  I have not connected the midi thru - see diagram (not connected)
  53.        Check this - I presume you can do it as the current does not
  54.        have to flow unless its connected ?
  55.  
  56. Pin-4 of MIDI THRU and +5v are connected through 220 Ohm resistor.
  57. So do Pin-5 of MIDI THRU and pin-4 of 74LS04 (inverter).
  58.  
  59.        NO I Did NOT connect the MIDI IN's GND
  60.  
  61. This is correct.  MIDI IN's ground is not connected.
  62.  
  63.    4]  OK this is the one I am not sure about - the IC's pin numbers
  64.        There is a little dot in the lower left hand corner of the 
  65.        6N137 (looking at it with the 6N137 number visable) I took this
  66.        to be pin one - the one above pin 2 - the one to the right pin 3 etc
  67.  
  68.        2 4 6 8    this method aggreed with the diagram looking from the solder
  69.        | | | |    side.  I used the similar idea with the Inverter ( bottom
  70.     6N137     left pin 1 )
  71.        | | | | 
  72.        1 3 5 7 
  73.  
  74. No. This is not how you number the pins.  You should number them in
  75. counter clockwise direction starting from the pin with little dot.
  76.  
  77.            8  7  6  5
  78.            __________
  79.           |_         |
  80.            _]        |
  81.           |._________|
  82.            1  2  3  4
  83.  
  84.  
  85. Hans.
  86.  
  87. ------------------------------
  88.  
  89. Date: Sat, 4 Dec 1993 12:47:13 -0500 (EST)
  90. From: Phat H Tran <ptran@sciborg.uwaterloo.ca>
  91. Subject: Patch Banking
  92.  
  93. > Date: Fri, 03 Dec 1993 12:11:50 GMT
  94. > From: Clarke Brunt <CLARKE@lsl.co.uk>
  95. > Subject: Patch Banking
  96. > 
  97. > > My sentiments exactly.  Patch caching has to be smart enough to look for
  98. > > Controller 0 and then cache patches from the right banks, but the driver
  99. > > would also have to respond to Controller 0 to switch banks on the fly.
  100. >
  101. [...] 
  102. > To use more than one bank at once, firstly MidiOutCachePatches would
  103. > have to keep any patches from other banks that you had already loaded
  104. > (see my question of yesterday), and secondly, the driver would have
  105. > to remember that it had loaded (say) patch 0 from bank 0, AND patch
  106. > 0 from bank 1, so that it could meaningfully respond to the controller
  107. > 0 messages and switch.
  108.  
  109. Yes!  
  110.  
  111. > Date: 03 Dec 93 09:40:59 EST
  112. > From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
  113. > Subject: Patch Banking Treatise
  114. >
  115. [...] 
  116. > The Custom Patch with Song File Opportunity
  117. >  ------------------------------------------
  118. >
  119. [...] 
  120. > If I make a song up that uses three custom patches and I put them in bank 33,
  121. > and then put it all up on the net, then you've got to install the patches
  122. > somewhere, and the ULTRASND.INI file must be changed. What if you already have
  123. > a bank 33 in use with some other patches in it? Then there's a problem.
  124. > 
  125. > I propose an application program be created that would be able to scan the
  126. > ULTRASND.INI file and create the bank entries for the music file you are
  127. > installing, with the correct patch names, and subdirs etc.
  128.  
  129. Adding a bank for each MIDI file that needs custom patches can become
  130. very unwieldy, but I guess it's the best we can do with the current drivers.
  131. Automating the bank entry editing would save a lot of hassle.  I think
  132. this function of processing a MIDI file, adding the new bank entries, and
  133. modifying the MIDI file to point to the appropriate bank should be 
  134. incorporated into some sort of patch librarian (Patch Man on steroids).
  135.  
  136. > Date: 03 Dec 93 11:16:40 EST
  137. > From: "Eric Bell, Howling Dog Systems" <71333.2166@CompuServe.COM>
  138. > Subject: Patch stuff
  139. > 
  140. > Let's see if I can remember how this works. As long as you are loading
  141. > additional patches on top of what is there, and ask for the patches that are
  142. > already there as well as the new ones, it will do an incremental load.
  143. > 
  144. > However, since melody patches are loaded under drum patches, any changes to
  145. > these, do cause the drums to be reloaded. 
  146.  
  147. Why not have the Windows driver fill GUS RAM from the bottom (0k) up
  148. with melodic patches, and from the top (1024k -- or 1016k if 8k is 
  149. reserved for WAV buffering) down with percussion patches?  This would
  150. save having to reload the drum patches each time a new melodic patch
  151. was needed.
  152.  
  153. To summary, I suppose this is what we would like to see in the Windows
  154. driver:
  155.  
  156. 1.  MidiOutCachePatches should keep previously loaded patches when called
  157.     upon to cache new ones.  The old patches should only be dumped by an 
  158.     explicit clear memory function (does one exist?), or if adding the
  159.     new patches exceeds available memory (in case some apps don't bother
  160.     to clear GUS memory before loading a new set of patches for a new
  161.     song).
  162.  
  163. 2.  MidiOutCachePatches should keep track of not only which patches have
  164.     been cached, but from which bank.
  165.  
  166. 3.  The driver should respond to Controller 0 to keep track of which bank
  167.     is active for _each_ channel.
  168.  
  169. If the above three points are implemented, then a sequencer can scan a
  170. MIDI file for Controller 0's and Program Changes and cache the 
  171. appropriated patches from the appropriate banks for each channel.  Then,
  172. as the song plays, the driver would be able to use patches from the correct 
  173. banks.
  174.  
  175. 4.  The driver should fill GUS RAM from the bottom up with melodic patches
  176.     and from the top down with percussion patches to avoid having to
  177.     reload the drums when a new melodic patch is cached.
  178.  
  179. Phat.
  180.  
  181. ------------------------------
  182.  
  183. Date: Sat, 04 Dec 1993 13:34:42 -0500 (CDT)
  184. From: TRIPLETT@swmed.edu
  185. Subject: Patch banking and custom patches
  186.  
  187. In GUS Musician's Digest V3 #4, Eric Bell writes:
  188.  
  189. >First off, I think it would be cool to create MIDI music using a few custom
  190. >patches, be the Hendrix samples, stuff from TV (ala MOD music), or specific
  191. >instruments with particular characteristics (flugelhorn, for example for that
  192. >Chuck Mangione piece you've been wanting to do).
  193. >
  194. >Is there a concensus out there that users would want to create and listen to
  195. >MIDI music in this fashion? That you would download someones composition 
  196. with
  197. >a few patch files that they'd created or appropriated, all zipped up together,
  198. >and that you could load onto your machine and play without much ado?
  199. >
  200. >Please squack if you think this is valuable, desirable, etc.
  201.  
  202. SQUACK, SQUACK, SQUACK, SQUACK, SQUACK !!!!!
  203.  
  204. Yes, indeed.  Since the possibility of multiple patch banks reared its head, 
  205. I have been wondering just how things would work out in reality.  I mean, 
  206. either we would all have to agree on a 'standard' set of patch banks that we 
  207. would all set up on our hard drives (with the same directory structure etc.) 
  208. so that we could all hear a composition as it was intended,
  209. or we adopt the kind of scheme you have suggested.  The former is 
  210. actually not a bad idea, and as I recall, has already been proposed in the 
  211. recent past.  I think this would work best in the long run if the other patch 
  212. banks were set up as variants of the GM set with changes appropriate for 
  213. different styles of music (ie, a rock-n-roll set with better guitar
  214. patches, drums, maybe a wider range of sounds in the synth and keyboard 
  215. sections of the GM set, and so on).  Again, I think this was the essence of 
  216. the recent suggestion.  That way, someone without the custom patch bank 
  217. will still be able to hear something that sounds ok, when using the 
  218. standard GUS patches, and the number of zip files bloated with extra stuff 
  219. would stay small.
  220. But... this does not provide for compositions with unique patches such as 
  221. Eric described. The problem I have with the scheme he proposed is that it 
  222. sounds pretty complicated.  Why not use an approach like the *.cfg files 
  223. for Playmidi?  The only complication is the patch banks and how to work 
  224. them into the scheme.  Well, it seems to me we could all agree to 
  225. leave one or several patch banks unused that all custom stuff would 
  226. default to.  You unzip the midi file and custom patches into whichever 
  227. directory you want, play the file, the calling program (or the windows 
  228. drivers) scans the directory for a *.cfg file, loads the custom patches in the 
  229. agreed upon empty bank, any other patches come from the default GM
  230. set, and the file plays.  Quick, painless, no editing of *.ini files, no 
  231. scanning for bank conflicts.  Even my grandmother could figure it out 
  232. <g>.  
  233. So what is your opinion?  Maximum flexibility, or some agreed upon 
  234. standard procedure that hopefully would be less complicated to use, let 
  235. alone implement in software?
  236. So now I will sit back and wait for the results of my first post (!). 
  237. Bye all,
  238. Terry (aka triplett@utsw.swmed.edu)
  239.  
  240. ------------------------------
  241.  
  242. End of GUS Musician's Digest V3 #5
  243. **********************************
  244.  
  245. To post to tomorrow's digest:                        <gus-music@dsd.es.com>
  246. To (un)subscribe or get help:                <gus-music-request@dsd.es.com>
  247. To contact a human (last resort):              <gus-music-owner@dsd.es.com>
  248.  
  249. FTP sites:           archive.epas.utoronto.ca              /pub/pc/ultrasound
  250.                      wuarchive.wustl.edu            /systems/msdos/ultrasound
  251.                      archive.orst.edu                    /pub/packages/gravis
  252.                      theoris.rz.uni-konstanz.de                /pub/sound/gus
  253. FTP mail server:     mail-server@nike.rz.uni-konstanz.de
  254.  
  255. Hints:
  256.       - Get the FAQ from the FTP sites or the request server.
  257.       - Mail to <gus-music-request@dsd.es.com> for info about other
  258.     GUS related mailing lists (general use, programmers, etc.).
  259.  
  260.  
  261.